It is commonplace for computing devices to incorporate power management features to support operating in various power states that each strike a different balance between consumption of electric power and availability of features to perform various tasks. In particular, portable computing devices tend to have rather sophisticated forms of power management in which the provision of the limited electric power available from a battery to various components is individually controllable.
For many of the uses to which a computing device may be put, it is often possible to allow a power management component to place the computing device in a lower power state. However, situations do arise in which it may be desired to maintain a computing device in a higher power state, and therefore, it may be desired to prevent a power management component from placing the computing device in a lower power state. By way of example, a computing device may be operated to perform playback of motion video, thereby requiring uninterrupted use of sufficient processing resources to decode motion video and uninterrupted use of a display to visually present the motion video. Further, such uninterrupted use of such resources may be required despite a limited supply of available electric power approaching depletion (e.g., despite a battery of the computing device running low).
It has therefore become commonplace to provide function calls to allow application routines and/or various portions of an operating system to request that a power management component of a computing device refrain from placing the computing device in a lower power state. This has become commonly referred to as requesting or “acquiring” a “wakelock” in which a computing device is “locked” into a higher power state or “kept awake” such that it cannot enter a lower power state or “sleep mode.” Various implementations include support for calls to request a wakelock, calls to release a wakelock and/or calls to request a wakelock that is time limited such that it expires at the end of a specified period of time.
Unfortunately, the provision of such support for application routines to make use of wakelocks has been accompanied by the advent of so-called “no-sleep wakelock bugs” in which errors in application routines and/or other unexpected situations arise that result in excessive use of a wakelock, thereby leading to premature depletion of available electric power. These situations are sometimes referred to as “unexpected battery drain” and lead to debugging efforts to identify the manner in which a wakelock was somehow requested and granted, but never released.
Unfortunately, numerous portable computing devices incorporate operating systems that were not architected in a manner that facilitates quick detection of the source of such wakelock bugs. Various operating systems do support the generation of system log data that details the occurrence of various events over time. Also, various operating systems do support the ability to “dump” the current state of registers and various data structures to provide a detailed view of the state of components of the operating system, including whether there is a wakelock that was earlier requested, but which has not yet been released. However, no provision has been made to record or provide the data necessary to identify what routine or operating system component may have errantly requested a wakelock and/or neglected to release a wakelock.